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1. INTRODUCTION 

Many command headquarters, such as the AF ^73L Command and Control 
System In Washington, are being equipped vith advanced data processing 
and display systems. These systems are designed to assist the command 
personnel in the execution of their assigned tasks. Although considerable 
progress has been made in the application of data processing equipment to 
the solution of the complex problems in command and control, there is still 
a great need for further developments of operational concepts and proce- 
dures to provide optimum utilizations. Such developments have not 
matched either the grovth of problem diversity and complexity or the 
potential capabilities of the processing equipment. 

Consider the following. In most operational command and control 
problems, such as are the responsibility of ^73L personnel, a large 
number of assessments must be made on the effects of individual decisions 
or on the effects of particular elements of the situation in determining 
the outcome of an operation. In addition, the overall data base of a 
command and control system is very large, covering many aspects of own 
force status, enemy disposition and activities, weapon performance data, 
and geopolitical factors. Thus, the solution to any given operational 
problem requires a careful selection of the pertinent parameters from the 
data base and then a careful assessment of actions to attain the desired 
goals. In a command and control system headquarters, it may frequently 
occur that the exact situation does not match any preplanned contingency 
situation for which a solution has been programmed. In such a case, the 
preferred solution would be the generation of a new program composed of 
a new combination of selected data to meet the peculiar operational 
situation. A less satisfactory but more normal answer, due to the 
permissible operational time factor, would be the employment of a 
modified or extrapolated existing plan or solution for meeting a given 
contingency. 

This technical note reports favorably on a preliminary investigation 
of the application of the On-Llne Console/Computer Technique to the field 
of command and control. A follow-up to this very preliminary work should 
be able to show that the above desired first approach to the solution of 
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unforeseen command and control problems can be realized in many cases. 
The time required for developing the needed computer programs, using 
the on-line techniques, should be relatively short. 

Section 2 summarizes the results obtained in this note. In Section 
3 basic principles for determining the application of the on-line 
console/computer techniques to the k'J3L Command and Control System are 
discussed. This is folloved (Section k) by a brief description of 
certain features of command and control systems that vill have a 
bearing upon the application of the on-line technique. Section 5 is 
a generalized discussion of the implementation of the on-line system 
to the command and control field, with particular emphasis on the ob- 
jectives, programming implications, and operating procedures. These are 
illustrated in an examination of a postulated operational problem in the 
last section of the main body. A brief appendix describes the particular 
console/computer facility, the RW-i^-OO system, used in developing the 
material of this note. 
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2. SUMMARY 

The on-line console/computer operation has had a high degree of 
success in solving complex scientific problems by Drs. B. D. Fried 
and G. J. Culler of this Division. The intuition and experience of 
the scientist has been successfully mated \rith the processing capabili- 
ties of a large computer/display console set-up in achieving this goal, 
without requiring the scientist to have a detailed knowledge of either 
computing equipment or programming. A successful transfer of this 
on-line technique from the scientific field to the command and control 
field would permit the command personnel to combine their training, 
experience, and knowledge of specific military situations with the data 
retrieval, display, and processing capabilities of the computer system 
at the command headquarters. Sufficient similarities appear to exist 
between the two fields that transfer seems possible. These are sub- 
stantiated by the analysis in this technical note. 

It should be recognized that the use of the on-line technique is 
envisioned as a supplement to current preplanned computer programs. 
The preplanned or off-line programs will continue to provide solutions 
to those problems which have been evaluated many times before. The 
on-line technique holds promise of reducing the cumbersome time consuming 
chain of operations involved in computer solution to new or infrequent 
problems. This chain consists of command personnel presenting their 
problem to programmers who program the computer to solve the problem 
which is printed out and presented to the command personnel for evalua- 
tion. Many iterations of this operation are frequently required. The 
on-line technique should permit command personnel, quite unversed in 
computer and programming techniques, to obtain essentially direct 
solutions to their operational problems. 

The preliminary investigations of this note do indicate that a 
feasible software system may be designed to expedite the solution of 
highly unstructured problems such as exist in the command and control 
area. Early in these investigations it became apparent that it would 
be helpful to list those characteristics of a computer that would aid 
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in the solution of on-line data processing problems rather than to 
select a given computer and attempt to implement the various processes 
in machine language. The desired characteristics include capabilities 
to; 

a. Interpret and execute commands given in a problem- 
oriented language, 

b. Manipulate variable length operands. 

c. Permit the user to define operands at his discretion 
in the on-line system. 

d. Modify on-line routines. 

At the same time, since it was obviously impossible to design and 
construct a computer having the structure and logic capabilities 
listed above, it vas decided to study the feasibility of simulating 
these characteristics on an existing computing system. The RW-^OO system 
was selected, principally because it is now being used with the scientific 
on-line work within the Division. 

The simulation of the above characteristics should be possible by 
implementing an Interpretive Program in which the instruction repertoire 
effects the manipulation of operands by transfers to and from a variable 
length Pseudo Accumulator. The operands are defined either by the identi- 
fication of items displayed on the cathode-ray tube of the display console 
or by overlay techniques. In this simulation, the interpretive program 
must contain: 

a. Control portion for the interpretation of console signals, and 

b. Operational portion for the retrieval of the necessary 
parameters required for the execution of the desired commands. 

Also it became apparent that a well defined file structure is required 
for the proper association of the various functions of the desired 
problems to the hardware through the interpretive program. 
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3. TECHNICAL APPROACH TO THE ON-LINE CONCEPT 

The problem of man-machine communications has been the subject of 
many studies and investigations. . Many different techniques have been 
devised to improve the man-machine relationships. One such technique 
was developed by the TRW Computer Division as part of an Air Force 
contract for a data processing system to reduce reconnaissance data. 
This technique involving the use of a display analysis console (DAC) 
allowed, in effect, direct communications between an operator (unversed 
in computer technology) and the computer. The console featured CRT 
displays and a set of pushbutton keys. The computer was preprogrammed 
to recognize the meaning of each key. The keys themselves were 
inscribed in the terminology of the operating personnel. A given 
problem solution involved a step-by- step routine of instructions 
(button pushes) by the operator, and performance and display by the 
computer. In many cases, the operator was given a choice of several 
alternatives at each step of the process. 

Although this represented a significant advance in man-machine 
communications and allowed the operator a degree of flexibility, the 
fact remained that each of the steps in the process had to be carefully 
thought out and preprogrammed by conventional methods. 

Recent extensions of these techniques have been successfully made 
by TRW with the development of the on-line computer technique to the 
solution of scientific problems. A scientist, without having to have 
a detailed knowledge of computers or programming, can impart his 
specialized knowledge, experience, and intuition at each step in the 
solution,* 



* G. J. Culler and B. D. Fried. "An On- Line Computing Center for 
Scientific Problems", TRW Computer Division, Report M19-3U3, on 
AF 30(602 )-2762, 11 January I963. 
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3.1 THE GENERAL ON-LINE CONCEPT 

The on-line con sole /computer technique attempts to overcome some 
of the problems present in the area of man-machine communications. 
The term "on-line" is used to emphasize the fact that the user (command 
personnel, scientist, etc.) has the capability to direct, to control, to 
monitor, and to modify the computational processes being performed on 
the data processing equipment at each major step in the process. This is 
different from the off-line technique where the user must first explain 
the problem and proposed method of solution to a programmer. The problem 
is then programmed, run on the computer, printed out, and returned to the 
user. The user must analyze the result, and then will generally suggest 
i;evisions in the method of attack or in the parameters, requiring a re- 
run of this cycle. 

The on-line scientific console/computer technique makes use of three 
features. These also appear to be equally applicable to the command and 
control field. The features as applied to the scientific area are: 

a. Functional Orientation - The programming structure is such that 
the computer presents mathematical functions rather than individual 
numbers to the user. These constitute the basic elements, while a reper- 
toire of "commands" consists of operations on functions (e.g., arithmetic, 
differential and integral operations, etc.). 

b. Control and Display Capability - Central to the operation of the 
system is a control console having a number of pushbuttons or keys, which 
allow for user control of the computer, and having a CRT display (with 
line-drawing capability), which provides direct graphic representation of 
the computed results. A CRT with alphanumeric capability and an automatic 
typewriter provide numeric outputs when required. 

c. Console Programming - A simple procedure allows the user to 
construct new subroutines directly at the console, using as building 
blocks an initial set of preprogrammed subroutines, plus any subroutines 
previously created by his "console programming" procedure. 

These features allow the user to apply, simultaneously: (l) his own 
intuition and si)ecialized knowledge, and (2) the very rapid and powerful 
computational capabilities of a computer to the solution of a given 
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problem. These features further allow the user to create new and 
special routines or steps without learning conventional programming 
techniques. He is able, using only normal mathematical concepts, to 
create a computational language tailored to his needs, and to the 
particular problem. 

3.2 APPLICATION TO COMMAND AND CONTROL 

It should be emphasized that the intention of the on-line effort 
in the command and control field is not to transform command and 
control problems into mathematical equations for solution by present 
scientific on-line techniques. Rather, the purpose is to investigate 
the feasibility of applying the on-line concepts directly to the command 
and control field utilizing the language and concepts of the user. 

The experience of the TRW Computer Division in the command and 
control field* and our preliminary analysis on the application of on- 
line console/computer techniques to command and control give every 
indication that this will be possible. This belief is based upon four 
points: 

a. Analogy of Problem Solution - The generalized methods (not 
specific techniques or mechanics) used in solving complex command and 
control problems are quite analogous to the generalized methods used 
in attacking and solving complex scientific problems. In both cases, 
the solution is highly dependent upon the experience and judgment of 

the personnel concerned. Furthermore, as mentioned previously, the deci- 
sion or solution can only be reached after numerous assessments of many 
factors. This requires a step- by-step process, with each step or alter- 
native dependent upon the experience and intuition of the user in the 
evaluation of the previous step. 

b. Common Features - Many command and control problems have common 
or similar features, and hence, would appear to be amenable to solution 



^ These studies have provided a very broad and detailed knowledge of 
command and control problems in the Air Force, Army, and the 
National Military Command Systems Support Center. 
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by similar techniques. The general techniques and methodology employed 
by command personnel in a given command post, such as 473L, appear to 
be very similar for a wide variety of specific operational problems such 
as those dealing with operations (general or limited war), logistics, and 
disaster. 

c. Basic Language - It is considered that command and control 
problems have enough common features to allow the existence of a common 
basic language. The existence of such a language is a prerequisite for 
the application of on-line techniques. 

d. Elemental Problem Fonnulation - Preliminary investigations, 
discussed more fully in Sections 5 and 6, indicate that command and 
control problems can be subdivided into basic elemental steps and 
processes. These steps appear to have universal application to many 
specific command and control problems. 

From these four points, it appears that the three major features 
of the scientific on-line computation technique will also describe the 
command and control on-line technique. Of these, the last two, "Control 
and Display Capability" and "Console Programming", appear to be directly 
applicable. This does not mean that the same display formats and console 
key labeling will be employed, but rather the same basic concepts of 
the user having control of both the data to be presented and the method 
of presentation. The other feature, "Functional Orientation", must be 
redefined to meet the language and concepts of command and control 
rather than that of mathematics. 
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k, CHARACTERISTICS OF COMMAND AND CONTROL DATA PROCESSING 

Before proceeding with the discussion of the application of the on- 
line technique to command and control, certain features of command and 
control systems should be presented. These features appear to have a 
significant influence upon the application of the on-line techniques to 
command and control. In many cases, these features are different in 
significant ways from similar features of scientific problems. 

The first two features of significance are the size and character of 
the data "base. The data base is generally very large, measured in terms 
of millions of items for such systems as k'J'^. The items are largely 
alphanumeric rather than numeric in nature. Typical extensive files in 
any one of these systems deal with such subjects as the status of forces 
and various contingency plans. 

A third feature of interest deals with information presentation 
techniques. A commander most often uses data in tabular form or on maps 
to solve a specific command and control problem. Textual material is 
also frequently used, but mathematical equations or their graphical 
representations are seldom used. 

These three features produce, in large measure, the fourth feature 
of interest, namely the processing operations employed by the command 
personnel. Pertinent selection and retrieval of data from the large data 
base are of prime importance. The actual selection criteria will depend 
upon the problem being solved. These selected data must then be pre- 
sented to the requesting command personnel in an easily grasped manner. 
The operations performed on these recalled data consist largely in re- 
arranging and in matching (such as objectives with resources). The end 
results are an operational plan and the issuance of frag orders. 

Another feature of command and control system data files deals with 
their continual updating. Specific entries, particularly in the status 
files, are being replaced by more recent information, while the general 
structure of the files remains unchanged. This operation is generally 
off-line from the command function. 

Thus command and control system operations can be characterized by 
data selection and retrieval, display, re-ordering, entry, and storage. 
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Computations, in the mathematical sense, play a minor role. 

Although these features may appear to be quite different from those 
present in scientific problem solution, there are actually similarities 
between the two. The scientific problem has a numeric data base in the 
functional parameters (frequently the real number system). This base is 
much less complicated from a data processing viewpoint than alphaniimeriQ 
data. The presentation of the data obtained in scientific problem solu- 
tion is usually tabular (all numeric), or graphical (used predominately 
in scientific on-line results). Finally, there are the scientific opera- 
tional processes. These are the well-known ones of arithmetic and 
advanced mathematics. 

Thus the problem in applying the on-line console/computer techniques 
to command and control is how best to adopt the man-machine interface 
through the console to the specific features of command and control 
operations. This note reports on preliminary investigations along this 
line. 
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5. BASIC PROGRAMMING ASPECTS FOR 
ON-LINE COMMAND AND CONTROL 



The adaptation of the scientific on-line technique to the command 
and control field must be based upon developing an appropriate relation- 
ship between the command personnel at the console and the data pro- 
cessing system. This relationship must encompass the peculiarities of 
the command and control field. 

Figure 1 illustrates this man-machine relationship. The console 
operator should use a command and control language both in viewing the 
console displays and in making entries with the control keys. The 
computer, on the other hand, operates in its own computer language. 
For a successful on-line system, interpretive programs are needed to 
link the two languages. Thus, when the operator depresses a control 
key, inscribed in command and control language, a signal is sent to the 
computer. The computer must then Interpret this signal in its own 
language. Similarly with computer-to-man communications, the computer 
must generate signals which represent raster points on the display. 
These points must, in turn, be interpreted by the operator in his own 
command and control language. 

5.1 ON-LINE OBJECTIVES 

This subsection considers how two of the basic features of the on- 
line technique could be instrumented in fulfillment of the above discussed 
basic concepts of man-machine relationships. In doing so, they are 
required to lie within a framework of practical objectives and constraints 
which will, in the future, undoubtedly be augmented and modified continu- 
ally as the various postulates are tested. These features are: 

a. Capability of the user to communicate with the computer in a 

"problem oriented" (command and control oriented) language. 

(l) Semantic Problems - Since we have not postulated the specific 
vocabulary to be used in the problem- oriented language, it 
is impossible to enumerate those words which will give rise 
to various interpretations by different users. However, it 
is interesting to note that the on-line system is designed 
so that the operator can define any item with which he is 
working in his own terminology. Semantic difficulties 



-11- 




Interpre- 
tive 

Program 
and 

Computer 

Language 



OPERATOR 



CX)NSOLE 



COMPUTER 



Figure 1, Man-Machine Relationship for On-Line 
Command and Control 



-12- 



should thus "be minimized. This is true when an overlay- 
on the console is used by the person who generates it. 
Quite possibly there may be explanations required if 
one person uses an overlay generated by another person. 
However, because of the similarity in background and 
experience, it is felt that the terms used by one person 
should be readily recognized and interpreted by a second. 

(2) Syntactic Problems - Undoubtedly syntactic problems will 
arise as the study progresses. For instance, it is well 
recognized that various combinations of mathematical 
expressions are subject to strict rules of syntax. Extra- 
polation to a command and control language would indicate 
that a high probability exists that the ordering of 
commands as stated by the user may be different from the 
execution sequence. This re-ordering will have to be 
accomplished by means of syntactic rules, which must be 
carefully worked out in developing the software for an 
on-line command and control system. 

(3) Instruction Phraseology - In addition, a very desirable 
characteristic would be the inclusion of .the capability 
for the system to carry out a given task quite independent 
of the exact phasing of the inputted statement. Thus, two 
operators would not need to employ exactly the same 
phraseology and syntax in their instructions to the data 
processing system. 

b. Capability for on-line modification of subroutines and creation 

of new subroutines. 

(1) On- Line Console Programming - The nature of command and 
control problems dictates the requirement for on-line 
generation of routines. As with other unstructured problems, 
it is not possible to anticipate and enumerate the various 
contingencies that may arise; therefore, the system must 
have the capability of allowing the user at a console to 
alter the program in accordance with the circumstances of 
the moment . This will achieve great savings in time and 
efficiency. 

(2) Program Implementation Techniques - Two techniques are 
available to implement on-line generation of programs. 
The first permits insertion of machine language commands 
into the system, while the second involves use of the 
"Program" key. With this key, a series of routines can be 
combined into a new single program, directly at the con- 
sole, from previously generated subroutines. It is 
implicit that in an operating system the desirable capa- 
bility should be vested in the Program Key rather than in 
the construction of routines in machine language. 

As an aid to determining the feasibility of Implementing the concepts 

of an on-line system in the command and control field, certain of the 
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constraints that might be imposed by an operational system should be 
altered or relaxed. In particular, those characteristics imposed upon 
system operation by the selected data processing system (specifically 
those of the DAC console) vill be used without modification. (Appendix 
A gives a brief description of the RW-i<-00 computer/console facility used 
in this note.) Also, any constraints that an operational system might 
impose with respect to the time required for either data search or 
internal program execution will not be considered. 

5.2 PROGRAMyUNG IMPLICATIONS OF ON-LINE CONCEPTS 

Since we postulate that a command and control language should be the 
basic input to the operational programs (the operator at the console in 
Figure 1), it is evident that an interpretive program must recognize and 
respond to the various inputs. For the present study, it is assumed that 
inputs to the interpretive program are generated by means of signals sent 
from a display console. (Other inputs may be added later.) 

Thus, if generic groups of keys can be assigned to generic functional 
groups of input instructions, a simplification to the interpretive program 
should be achieved. To date a specific vocabulary has not yet been 
postulated; thus, a modified and generalized concept will be employed by 
associating two major generic groups of keys on the console with Operands 
and Operators. This generalization should pertain to any language, and it 
is hoped that it will serve as an adequate vehicle for the transition 
between the machine language and a command and control language. 

Following this premise of generic grouping^ the work reported in 
this note is based on the assumption that the console display control 
keys, DCK's, will serve to define operands. These become the entities 
utilized in attempting to solve a specific problem. It is expected that 
in the command and control area, as in any class of problems, they will be 
limited in number. The on-line system must include an inherent capability 
to permit the operator to define operands as he desires . 

Operations, on the other hand, will be assigned to the process step 
keys, PSK's, to effect transformations on operands. Study indicates 
there will effectively be two classes of operations; one hardware function 
oriented and the other class problem oriented. An example of the first 
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class is the command "DISPLAY", and of the second or problem-oriented 
class "COMPUTE DISTANCE". 

One logical conclusion reached from postulating the concepts of 
operations and operands is that a vehicle must be provided to effectively 
carry out operations on operands. Drawing upon the analogy of computer 
design, it appears that a "Pseudo Accumulator" would be expedient. 

In analyzing these concepts for implementation, it becomes apparent 
that certain properties should be fixed. Among the most significant are 
the display capabilities of the DAC console. Specifically, only a maximum 
number of characters can be displayed on the alphanumeric 10-inch tube 
and a maximum number of symbols on each of the 17-inch tubes. 

From the problem- solving aspects of the system, it seems apparent 
that: 

a. Decisions and intermediate actions will generally be based on 
information that is displayed on these tubes, and 

b. The console will serve as the principal input medium. 

It is, therefore, tentatively concluded that operands should have a 
connotation with respect to the cathode-ray tubes as well as the display 
control keys. This also seems to be consistent in that it would be 
desirable in many cases to label an item that appears on the screen. 

Two significant conclusions result from this concept of associating 
an operand with a display: 

a. There is an implication that an operand will not be of a pre- 
assigned size. This in effect says that both operands and the 
pseudo accumulator should be considered to be of "Variable 
Length" . 

b. From a consideration of the types of information that would be 
called operands in a command and control system, it is obvious 
that any operand could be made up of parts. For example, a 
status report could very well be considered from a functional 
standpoint as an operand. However, it is just as obvious that 
there must be a capability of manipulating component parts as 
well as the whole operand. Each component part could be given 
the name "Sub-Operand"; however, it is felt that a better term 
is "Element". 
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We thus postulate that within the on-line system it is necessary to 
provide for the manipulation of elements as veil as operands. Thus, 
operations will be defined, insofar as possible, to act similarly on 
either operands or elements. 

5.3 PRELXMINARY FROGRAMMENG SYSTEMS SPEGIFICATIOIUS 

5.3*1 Control Program 

A control program must he in core at all times to recognize and 
interpret messages received from the DAC keyboard. Recognition is 
Implemented via an alert or interrupt system. At the start these 
signals are locked out unless that computer is ready to respond. Inter- 
pretation of an interrupt signal, of course, depends upon the format of 
the message sent from the console keyboard.^ 

5.3*2 Interpretive Program 

Signals sent by the console keyboard represent instructions from the 
human operator to the computer. Since the format of the signals generated 
by each key is unique, it is apparent that each must be interpreted with- 
in a specified framework which, in general, is an "overlay". By a process 
of labeling and programming, it is possible for the operator to assign 
functions at his discretion to specific keys within a generic group. 

From these postulates two characteristics of the interpretive 
program can be specified: 

a. The capability of identifying and retrieving all programs 
associated with a given overlay. 

b. The capability for responding to the implicit request of a 
labeled key by means of the unique signal generated. 



* For the message format used on the DAC, it is necessary to isolate the 
signature portion from both the message portion and the end of message 
portion. In general, the signature portion is used to identify a 
specific table which associates the depressed key with its specified 
task. The message portion is used to obtain a value from the table 
selected by the signature. The value in the table is then used to 
transfer program control to the proper place in the interpretive program. 
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It should be noted In this regard that Process Step Key No. 1 on the 
DAC Initiates a unique interpretive program used to identify and 
retrieve the program for the overlay in position (Section 6.3«l). 

In addition, the concept of generic groups of keys can be exploited 
for partially systematizing and characterizing the capability of the 
system to respond to signals through the ■ interpretive program. The next 
two subsections give a more detailed explanation of the character of 
the interpretive program with respect to the display control keys and 
the process step keys. 

5.3»3 Display Control Keys 

This group of keys, devoted to designating operands and/or elements 
of operands, are the entities to be manipulated in the computer. The • 
general conditions and restraints of their manipulation are specified 
below. 

As with symbolic programming, an item is catalogued by its name by 
the user, and by its assigned location by the computer. In addition to 
its location within the computer, each item must have associated with it 
a number of other parameters. The first is a measure of sizej i.e., 
the number of words or number of characters. This results from the 
variable length Characteristic for both operands and the pseudo accumula- 
tor. For elements, an additional parameter is required, namely its 
relative location with respect to the operand of which it is a component. 
Conceptually, it may be required to add another associated parameter, 
the identification of the module of the data processing system which 
contains the specified item (tape, drum, etc.). This, of course, is a 
function of the computer system utilized. 

In summary, for each item stored in the computer, a need exists foxv 
explicitly identifying up to four parameters. These will be utilized by 
the interpretive program. They are: 

a. Module in which the item is stored. 

b. Absolute location of item. 

c. Relative location of item. 

d. Size indication. 
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Several techniques can be proposed for making these parameters available 
to the program. For example, these could be included as a portion of 
the item itself or in a table of parameters for each DCK (Display Control 
Key Table). The latter is employed in this note. 

5.3*^ Process Step Keys 

These keys are used to identify the operations (manipulations) to 
be performed. In an operational overlay, it is probable that they will 
be rather complex sequences of simpler, pre-defined operations. The 
essential problem is thus to analyze the requirements imposed by the 
interpretive program at the machine level. 

The employment of generic key groups has essentially specified that 
a command or instruction to the computer requires at least two key de- 
pressions | one to identify the operation and the other to specify the 
desired operand. In other words, the interpretive program needs a 
complete sentence consisting of a subject and a predicate to establish a 
meaningful statement. One without the other is meaningless. 

Overall, the interpretive program will utilize the pseudo accumulator 
in a manner analogous to the utilization of an accumulator by a conven- 
tional computer. Thus most, if not all, of the interpretive instructions 
will use the pseudo accumulator as either a source or target location. 
This provides an insight with respect to the required groupings of 
machine instructions which make up the interpretive instructions. 

In the first instance, it is apparent that the machine language 
instructions must be supplied with source and target locations. In 
those cases in which an operand is involved, this information is avail- 
able from the associated Display Control Key Table. Also, because many 
operands may encompass multiple words, a loop must be formed to effect 
the desired results. This requires a counter to keep track of the number 
of times through the loop. The DCK Table should contain this informa- 
tion when pertinent. 

Overall, some of the requirements for the proper execution by the 
interpretive program of process step key signals can be summarized by: 

a. Machine language instructions 

b. Address modification instructions 



-18- 



c. Loop counting InBtructlons 

d. Pre-setting InBtructlons 

e . Storage in relocatable form 

f . Certain precautions with respect to instructions pertaining 
to the pseudo accumulator. Specifically, vhen instructions 
call for adding elements, it is necessary to ensure that 
the elements are added into the pseudo accumulator in their 
proper relative position. 

5.3»5 Hie Organization 

It is anticipated that it will be possible to construct and maintain 
overlay programs in some storage medium, such as magnetic tape. For 
this purpose it is expedient to have a rather explicit file structure for 
the component parts of the overlay programs. To this end, some of the 
component parts have already been indicated in the above section. Over- 
all it appears that the file structure should consist of four records or 
parts: 

a. An identification corresponding to the signature. This record 
should serve as a key for retrieving the remainder of the file. 

b. A record consisting of a series of tables, one for each generic 
group of keyboard keys. 

For these two records it seems possible to establish fixed length 
formats. For the DCK's, the required parameters will form one table 
(the DCK Table). For the PSK's, the location of instructions In aiJXillary 
storage must be identified (Section ^»3,k). Similar tables will be 
required for every other generic group that is defined. At present it is 
not clear whether these tables should be kept in core storage for fast 
access at all times or whether they should be placed in auxiliary 
storage and brought into core on demand. If the latter is required, 
there must be an auxiliary table for retrieval of these records. 

The last two records are: 

c. A record of all operands ordered in accordance to DCK Table 
number. 

d. Those groupings of machine instructions required to execute 
the command as expressed by any process step key. 
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Definitions for other records will depend upon the asBignments 
allocated to other generic groups of keys. It is apparent that the 
last tvo records will, of necessity, be of variable length. This will 
require either a table or imbedded parameters to permit retrieval of 
specific groupings. 

5 A OPERATING PROCEDURES 

This preliminary study indicates that the solution to a command and 
control problem by means of an on-line computing system requires follow- 
ing a fairly standard procedure. Eight steps have been formulated: 

a. The problem must be analyzed to isolate its various component 
parts . 

b. Each part must then be expressed in the "On-Line Command and 
Control Language" . These expressions or parts naturally contain 
manual translations. This emphasizes the desirability of 
devising a language which is close to that used in the problem 
area. It should also be noted that the ordering of terms with- 
in these expressions must follow the syntactical rules or 
constraints established for the language. 

c. As pointed out before, it is necessary to teve complete state- 
ments for proper execution by the interpretive program. It 
thus appears that a subsidiary step must be taken in order to 
isolate: 

(1) Operands to be defined 

(2) Operations to be "programmed" 

This requires analysis of each statement to segregate the two 
parts stated. 

d. By use of (l ) a standard overlay containing operands pertaining 
to hardware characteristics, and (2) a set of standard operations 
which had been queued upon generation of the overlay, the opera- 
tor must "define" all operands and label the corresponding 
display control keys, 

e. A second queueing procedure must allow the operator to compile 
previously generated operations. This will essentially entail a 
retrieval of information from overlay file(s) which contain the 
required operation. 

f. If a new operation occurs which is not in the "library", it may 
be necessary to program this in machine language and thus in- 
corporate it into the basic program. 

g. Upon assignment of all operations, operands, and any other 
grammatical terms that may occur, the operator should now be 
prepared to "Program" his operational overlay. 
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h. The final etep^ if taken, should be the generation of 
queueing lights under the PSK's and of queueing status 
lights for the DCK's. This step would be taken, primarily, 
to insure that the sequence of button pushes were ordered 
within the constraints of the syntactical rules. In those 
instances in which it is impractical to generate the 
required lights, the problem statements in the "command and 
control language" should suffice. 
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6. APPLICATION OF ON-LINE TECHNIQUES TO 
CONTINGENCY FORCE REROUTING 



This section of the note illustrates how the just enumerated con- 
cepts of the on-line console/computer technique can be applied to a 
specific operational problem. Although the chosen operational problem 
may not be one that would involve the command personnel of the k'J^l* 
Command and Control System, it is believed to be one that would involve 
personnel at a force command post level. Thus, it is felt that the 
chosen problem provides an adequate vehicle for showing how the commander 
and his immediate staff should be able to use the on-line technique for 
solving a new and unforeseen problem. 

The discussion of this section first states the operational problem 
(Section 6.1), and then gives the steps that the top command personnel 
might perform at a console for solving the problem (Section 6.2). One of 
these steps is then broken down into its component parts through the in- 
terpretive program (Section 6.3). It should be emphasized that the analysis 
of the problem presented in this discussion is quite preliminary. However, 
sufficient analysis has been given to indicate that the on-line concepts 
enumerated in Sections 3 and 5 do appear to have application to a specific 
problem. 

In order to be specific, the analysis has been applied to the RW-^00 
system. However, other display consoles and computers can be equally 
well applied to the on-line techniques by modifying the specific opera- 
tions to fit the constraints of the specific equipment. 

6.1 OPERATIONAL PROBLEM: CONTINGENCY FORCE REROUTING 

It is assumed that an operational exercise, Project Unicorn, is 
scheduled for Western Europe during the latter part of April. This 
exercise includes the deployment of several squadrons of fighter-bombers 
and other aircraft from the ZI to West Germany. 

Unexpectedly, on 25 April, the day a large part of the force is 
under deployment, a political situation arises in Germany. The situation 
is such that it would be to the detriment of the United States for a 
large military force suddenly to appear in Germany. Thus, the Project 
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Unicorn exercise is cancelled. However, there are various flights 
already enroute to Germany. 

The problem facing the commander is hov best to divert the forces 
enroute in order to minimize the political implications and to save the 
men and equipment. New destinations must be found for the airborne air- 
craft. These destinations must also fit .within both the operational 
constraints and political constraints erected by the unforeseen situa- 
tion in Germany. This is a problem, whose specific parameters and maybe 
even its general parameters, were not foreseen during the planning 
period for Project Unicorn. Solution time is very limited. This is a 
situation where the on-line technique should find its greatest usefulness. 

6.2 ON-LINE SOLUTION BY COMMAND PERSONNEL 

The on-line solution to the above operational problem requires a 
joint effort both by the senior operational personnel and by junior 
personnel who have some data processing training but are not programmers. 
It is envisioned that the operational personnel will first describe the 
problem, the suggested method of attack, and certain factors that must be 
considered by the junior personnel. The latter will then rapidly develop 
on-line the operational command and control overlay (program) for this 
particular operational problem from the basic overlays. The resultant 
Operational Overlay will then be used by the senior personnel in making 
the required command decisions by an on-line solution to the operational 
problem. 

This section discusses the steps that the command personnel might 
follow using the Operational Overlay on the DAC console. 

6.2.1 Set-Up 

The initial step is to inform the computer that the Project Unicorn 
force diversion problem is to be solved. For this purpose, the Project 
Unicorn Operational Overlay (as generated on-line by the junior personnel) 
is placed over the process step keys (PSK) of the DAC. (Figure 2 is a lay- 
out of the DAC keyboard for this problem solution.) The console operator 
then pushes the first process step key START to inform the computer which 
overlay is in position. 
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6.2.2 Mission Status 

The first operational step In the solution Is to determine which 
flights need be diverted. For this purpose, the mission status Is to 
be displayed on the alphanumeric tube. Due to the limited character 
capability of the tube (6^0 characters In 20 lines of 32 characters 
each), a clear plastic cover sheet Is placed over the tube face 
(Figure 3)« The column and row headings are Inscribed on the cover 
sheet. 

The console operator then pushes PSK MISSION STATUS TABLE. The 
display of Figure k then appears on the alphanumeric tube with the 
spaclngs shown. The second line of characters gives, on the left, the 
time (Greenwich mean time or Z-tlme) of this mission status report and 
on the right, the number of the group of mission status displays required 
to present all Project Unicorn flights. Since three displays are re- 
quired and four flights are given per display, the console operator 
knows that there are between 9 and 12 flights involved. A given flight 
may be one or more aircraft. 

Let us examine each of the flights in Figure k- as to its require- 
ment for diversion. Flight 15 is not scheduled until tomorrow (it is 
assumed today is 25 April). Thus the flight can be cancelled. To do 
this, the marker, a square shaped symbol on the DAC, is positioned on 
the alphanumeric tube under the item of interest. To do this, the 
operator pushes the key labeled MARKER DISPLAY/DISCONNECT to cause the 
marker to appear at the upper left of the tube. By successive pushes of 
the RIGHT button, the marker is advanced until it is under the "+" of 
Column 1 of the display. The operator now pushes the PSK CANCEL followed 
by the Marker Define Key COLUMN. This informs the computer of the 
cancelling of the flight and also notifies the appropriate operational 
personnel to issue the frag order. 

Next is Flight l6. It is bound for Ramstein, Germany, with the 
designated alternate of Bltburg, Germany. This flight must be diverted. 
The first step in doing this is to indicate to the computer that Flight 
l6. Column 2, is of further interest. The marker is again used. Use of 
the RIGHT key will advance the marker until it is under the "+" of 
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Notes on Figure k, Mission Status Display 



As of - Time of the information presented 

Display No. - Number of this display out of total number required 
to present all of the mission status data 

LTIOV - Time of last report 

Date - Month and day 

Time - Hours and minutes in GMT or Z-time 

TFS - Tactical fighter squadron 

TRS - Tactical reconnaissance squadron 

TCS - Troop carrier squadron 

E - Estimated time 

A - Actual time 

FUEL - Refueling 

- Zero character on display analysis console 
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Column 2 of the display. The PSK ITEM OF FURTHER INTEREST is pushed, 
followed by Marker Define Key COLUMN. This informs the computer that 
the material in Column 2 is of further interest.* In this specific 
example, it really means that Flight l6 is of further interest. 

Flight 18 (Column 3) is bound for France and thus may proceed. 
Finally, Flight 21 is bound for Germany, but the flight plan alternate 
is South Ruislip, Great Britain. This flight should be immediately 
diverted to its designated alternate. To do this, the marker is moved 
to under the "R" of "Ruislip" in Column k. The PSK DESTINATION is pushed, 
followed by pushing the Marker Define Key START, the marker is then 
positioned under "P" of "Ruislip", and the Marker Define Key STOP is 
depressed. This informs the computer and the appropriate personnel to 
issue a frag order to the pilot. 

The console operator is now ready to investigate the second group 
of four flights on Mission Status. For this purpose, he pushes the PSK 
labeled NEXT A/N DISPLAY. Data on these flights, similar to that shown 
in Figure k for the first four flights, is now presented. Examination 
of the material indicates that three of these flights are of interest. 
The marker is used to define these flights as items of further interest 
in a manner similar to the operation Just described for Flight l6. A 
second push of NEXT A/N DISPLAY key produces the third and last part of 
the mission status report. It is determined that no flights are of 
further interest on this display. The MARKER DISPLAY/DISCONNECT key is 
used to remove the marker from the screen. Thus there are four items 
(flights) of further interest in this operational problem. 



* An alternate procedure is first to move the marker under the "1" of 
the flight number "l6". The PSK ITEM OF FURTHER INTEREST is pushed, 
followed by the Marker Define Key START/STOP. The marker is then moved 
with the RIGHT and DOWN keys until it is under the "L" of "3 FUEL" in 
the remarks row of Column 2. The START/STOP key is again pushed. These 
two pushes of the START/STOP key inform the computer that all material 
between the two key pushes is of further interest. In this case, this 
is the material in Column 2. 
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6.2.3 Flight Location 

The console operator next vishes to determine the approximate 
location of the flights of interest (the four flights defined above). 
This is done using a map display on the right hand 17-inch tube of the 
DAC. The operator first places a clear plastic map of the North 
Atlantic over the tube face (Figure 5)* This is assumed to have a 
file number 352. The use of such an overlay does not require the 
console- computer combination to generate the complex fixed cartographic 
background. The operator also pushes RIGHT of the 17-inch tube selec- 
tion. 

The display desired is generated by the programmed process step key 
PLOT FLIGHTS ON MAP 352. This key is programmed to plot three data 
points for each of the selected flights, defined by the marker in the 
previous step, and to the proper scale of Map 352.''^ 

The points are: 

Present position (x) 
Destination (+) 
Alternate destination (o) 
The data on Figure 6 covers each of the four flights designated as ITEMS 
OF FURTHER INTEREST in the previous operational step. Note, however, 
that on the figure, only three destination points (three +'s) and three 
alternate destinations (three o's) are shown at only four places. This 
means that two of the flights have the same destination, two the same 
alternate, and that the alternates for two flights are the destinations 
for two others '(these pairs may or may not be the same). 

(it should be noted at this point that the on-line program back of 
PSK PLOT FLIGHTS ON MAP 352 is quite complex. The data required for this 
display are the latitude and longitude of three locations for each flight, 
correctly normalized to the correct scale and map projection (as Mecator 



* If an overlay map other than No. 352 is used, the console operator 
must first push PSK MAP NO., followed by the map niimber from the 
numeric keyboard. He then pushes PLOT FLIGHTS. The same data as is 
shown in Figure 7 will be plotted to the designated map scale. 
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Figure 6. Present Locations and Destinations of Flights 



projection) of Map 352. Now these latitude and longitude points vere 
not given on the mission status alphanumeric display. Two of the 
points (destination and alternate) were given by place name, and the 
third (present location) was not given in any manner. The computer 
program must recognize that defining a column means interest is in 
certain data items of the complete flight- plan for the flight in that 
column. Thus, the data desired for a 17-inch display need not be a 
part of the data on the alphanumeric display.) 

6.2.4 Individual Flight Plan Modification 

The command person at the console is now interested in rerouting 
each specific flight shown. To do this, he first points the light gun 
at the present position (x) of any flight.* The x then starts to blink. 

The next PSK button push is SELECTED FUGHT PLAN ON MAP 352.** 
This new push will produce both a cartographic display on the 17-inch 
tube and a new alphanumeric display. Since the operator may wish to 
retain Figure 6 on the display tube, he will first push the LEFT button 
of the 17-inch tube selection, and place a second Map 352 (Figure 5) 
over the left tube before pushing SELECTED FLIGHT PLAN ON MAP 352. The 
resultant 17-inch display is shown in Figure 'J, and the alphanumeric dis- 
play in Figure 8. It is assimied that Flight l6 (see Figure k) has been 
selected. From Figure 8 it will be noted that a new flight report has 
been received (later LTIOV) which has included a new estimated arrival 
time at Ramstein of 1515 Z instead of 1500 Z. Also, since the data to 
be presented on the alphaniMeric tube is more limited than for the mission 
status display, the headings are included in the display. From the map 
display (Figure 7) the operator can readily see that Flight l6 has 



* To cue the operator that this is the next step required, Status Light 
LIGHT GUN comes on following the pushing of PSK PLOT FLIGHTS ON MAP 
352 (or PLOT FLIGHTS). 

** If another map scale is used, the appropriate key pushes are PSK MAP 
NO., the appropriate numeric keys, and PSK SELECTED FLIGHT PLAN. 
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Figure 8. Alphanumeric Display of Hight Plan 



completed tvo of three scheduled refuelings and is nov approaching the 
coast of France. 

If this flight is to be diverted to another base, the operator must 
determine whether sufficient range remains. For this purpose, he pushes 
PSK RANGE REMAINING and light guns a point on the flight (current posi- 
tion, say).* The 17-inch display is then modified by the addition of the 
range remaining about the present position (without any scheduled re- 
fuelings).. Other points along the flight path may also be used as the 
center of the range remaining calculation. Figure 9 shows two range 
remaining curves, one about the present position, and one about the last 
scheduled refueling point for the flight. 

The operator next wishes to determine what airfields imder US 
Jurisdiction are available and within range of the aircraft for this 
flight. For this purpose the PSK US AIRFIELDS is pushed. These now 
appear on the left 17-inch display as dots. The computer is programmed 
such that only those airfields having adequate runways for the type of 
aircraft in Flight l6 (RF-101's) are shown. 

The operator notes that there are available airfields in southern 
Great Britain, France, and Spain. From a knowledge of the political 
situation that is causing this diversion of flights, the console operator 
knows that it will be politically unwise for combat type planes to land 
in France (C-130 transports of Flight l8. Figure k, will not cause a 
political situation). This type of information cannot be readily pre- 
programmed into the command and control system data base. Primarily on 



* An approximate equation for this calculation is: 
R = (V + W cos 0) (f/f) 
where R = range remaining 

V = airspeed of aircraft 

W = wind 

= bearing of wind from the flight path 

F = fuel remaining less reserves at point that is light gunned 

F = fuel consumption 
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Figure 9- Range Remaining Curves for Flight l6 



a political basis, the operator chooses a base in southern Great Britain. 
This is indicated to the computer and to other personnel by pushing the 
PSK DESTINATION and light gunning that base. The name of the destination 
now appears on the alphanumeric tube in place of the old one. (it should 
be noted that the PSK DESTINATION has two programs associated with it. 
One deals with the marker and the alphanumeric tube (Section 6.2.2); 
the other with the light gun and the 17-inch tube.) 

The operator now returns to the right hand 17-inch tube (Figure 6), 
light guns another flight and repeats the above procedure. Other 
process step keys have been programmed to provide the operator with other 
choices in this problem of flight diversion. These include FOREIGN AIR- 
FIELDS, AIR-SEA RESCUE unit locations, ENROUTE WEATHER, and TERMINAL 
WEATHER. 

6.3 UTILITY, SERVICE, AND BASIC PROGRAMMING FOR THE 
ON-LINE SYSTEM 

The previous section showed how an Operational Overlay could be 
employed by a senior command person with the on-line technique for 
diverting the flights of Project Unicorn that were enroute to Germany. 
This section shows how the basic concepts and programming of the on- 
line system can be employed by the junior command personnel to generate 
this overlay. Specific attention is directed toward developing the on- 
line processing steps required to generate the Mission Status Display 
(Figure ^), the display generated by pushing the second process step key 
of the Project Unicorn Operational Overlay (Figure 2). It should be 
noted that the following is an illustrative rather than an exhaustive 
discussion of the utility, service, and basic programs required for the 
on-line generation of the operational program. However, it is felt 
that the analysis presented backs up the basic assumption that the on- 
line console/computer technique can be applied to command and control 
problems. 

Before going into this discussion, the full significance of the 
first PSK START is explained. 
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6.3.1 FSK START 

The START key is common to all process step key overlays on the DAC 
console. It is used to inform the computer of the overlay in position 
and, hence, must be the first key pushed after an overlay is put in posi- 
tion. The interpretive program uses the message generated by this key 
to: 

a. Locate the program file associated vlth the specified overlay. 

b. Read into core the required PSK and DCK Tables associated 
with the overlay. 

c. Enter an idle loop awaiting subsequent key depressions. 

d. Light for operiator cue those PSK's which are program 
compatible for subsequent depression, a desirable but 
not necessary feature. 

6.3.2 On- Line Programming for PSK MISSION STATUS TABLE 

The second PSK on the Project Unicorn Operational Overlay (Figure 2) 
is labeled MISSION STATUS TABLE. The operand produced by pushing this 
key was programmed on-line by the junior command personnel, following a 
briefing on the operational problem. It was developed from: 

(a) The basic command and control programs with their 
associated console overlays and tables, and 

(b) The data base of the entire command and control 
system. 

The initial problem is one of searching, selecting, and extracting 
all pertinent information relative to Project Unicorn. The second problem 
is to formulate the data extracted into the required format for display, 
and to program the PSK's of the Operational Overlay. A part of this 
task involves developing the desired associations between the successive 
steps in the Operational Overlay. 

To see the problem in a slightly different perspective, it is 
necessary to extract from each flight record certain information needed 
for the display initiated by PSK MISSION STATUS TABLE. Additional infor- 
mation is required from the flight records (present location, destination, 
and alternate destination for PSK PLOT FLIGHTS). Finally, it is necessary 
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to otitaln those items required for PSK RANGE REMAINING. In addition, 
the operational overlay programs must contain data for properly inter- 
relating these various displays about the same flights. 

Thus, the following basic programming capabilities are required: 

a. Search data base 

b. Select items based on various criteria 

c. Extract specified information 

d. Compile extracted information into a working dfata base to be 
used with the Operational Overlay 

For an operational environment it will be assumed that on-line 
programs have been developed to implement these rather standard data 
processing activities. These are enumerated on a PSK Utility Overlay. 
Such an overlay would thus be utilized for programming on-line the 
requested operational overlay process step keys. It is obvious that the 
user must supply parameter values required by each utility routine. The 
implementation of the PSK PROGRAM thus becomes a most important link in 
the communication between the operator and the computer. 

6.3.3 Utility Overlay 

This section will give a rather detailed elaboration of some of 
the standard data processing activities that make up an Utility Overlay 
(Figure 10). The function of each of the process step keys will be 
discussed relative to the generation of a command and control system 
Operational Overlay. The related display control keys will be discussed 
as they occur. 

a. START - The function of this key was given above in 
Section 6.3.1. 

b. SEARCH - With this key the computer is instructed to look 
for items described by subsequently pushed display control 
keys. The implementation requires an explicit statement of 
either or both 

(1) Medium to be searched as. drum, tape, etc. 

(2) Operand identification. 

Thus, if the implementation uses, operand identification for a 
magnetic tape, file indication is needed; or for a drum, band 
or sector identification. In addition, the utility program 
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Figure 10. Utility Overlay 



must deduce that if no complementary word follovs, the opera- 
tion applies to the entire storage medium. 

In the proposed system, explicit definition of the storage 
medium Is required In the Display Control Key Table (Section 
5.3.3). This means pushing the DCK DATA BASE In the Utility 
Overlay (Figure 10). 

c. SELECT - It Is next necessary to specify the selection 
criteria. This will, In general, require pushing the PSK 
SELECT and one or more DSK's and/or PSK's depending upon the 
complexity of the retrieval request. Since It Is recognized 
that the request can "be a rather complex statement of logical 
and/or arithmetic descriptions, it is necessary to provide for 
these among the various process step key utility routines. In 
Figure 10 those PSK's labeled AUD and OR are typical examples. 
The selected data is placed in the pseudo accumulator. 

For the specific operational problem, selection is required 
for those items in the data base under the label OPERATION 
UNICORN. It is thus necessary to DEFINE the operand Operation 
Unicorn and assign it to an unused DCK. 

d. (Period) • - Because of the possible use of multiple PSK's to 
implement a given routine such as SEARCH and SELECT, it 
becomes apparent that the computer must be given a signal to 
execute; i.e., start the requested sequence. This is the 
function assigned the PSK "(Period) •". The "." also aids 

In establishing a notation for the communication of problem 
statements. 

e. (Comma) , - The comma is used to indicate to the computer 
that a type of parenthetical expression follows, in order 
to construct a meaningful statement. 

Thus, with the utility overlay keys defined so far, the instruction 
might be given: 

SEARCH DATA BASE, SELECT PROJECT UNICORN . 

This will specifically Identify the buttons to be pushed and indicate 
the proper place to commence execution. It is apparent that the command 
SEARCH DATA BASE is not by itself meaningful. 

f . EXTEIACT - Conceptually as soon as a selection is made and the 
data placed in the pseudo accumulator, all or certain parts of 
the selected record should be disposed of in a predetermined 
mnnner. This is actually a two step process: the tagging of 
those specific items wanted and the compiling of the new file. 
The PSK EXTEIACT instructs the computer to extract or tag each 
of the items defined by subsequently pushed DCK's, each 



-1^2- 



separated by the PSK ",". The operator will have defined 
the necessary DCK's for the items vanted on an Utility Over- 
lay. Figure 10 includes several such as FLIGHT NO., MISSION, 
UNIT, and TYPE A/C. Because of the large number of distinct 
keys required to enumerate the items to be extracted, the 
PSK "." is used at the end to tell the computer when to start 
the extraction process. 

A written statement of the actual console key pushes might be 
EXTRACT FLIGHT NO., MISSION, TIPE A/C 
As noted above, this instruction is not complete, in the sense that the 
ultimate disposition of the extracted items has not been made. This is 
the task of the next set of instructions. 

g. COMPILE - The elements extracted from a selected record should 
be regrouped and filed. To do this, the operation of PSK 
COMPILE is used followed by the DCK denoting the location for 
the elements, in this case the working data base. The essence 
of this operation is a connotation that all items flagged in 
the pseudo accumulator as a result of the EXTRACT operation 
are to be placed in the working data base; however, the rela- 
tive location of each element is determined only by the 
flagging sequence stated as a result of the display control 
key pushes after EXTRACT. The required statement for com- 
plementing the extract operation discussed above might thus be 

COMPILE K)RKING DATA BASE 

h. DEFINE - In order to use the overlays in the manner described 
above, it/ is necessary for a console operator to "define" the 
operands labeled on the various display control keys. 

Essentially, the information required to "define" an operand 
consists of those criteria needed to allow the interpretive 
program to access, manipulate, and store the items defined. 
More explicitly for each operand it is necessary to specify: 

(1) Storage medium of the operand. 

(2) Absolute address of the start of the operand. 

(3) Relative address of the start of sub-operand or element. 
(k) Number of words (or characters) in the operand, sub- 
operand, or element. 

This information is assembled for each operation and element 
as a table to be associated with the corresponding display 
control key (the DCK Table in Section 5.3.3). This then becomes 
the function of the PSK DEFINE button, namely to assemble the 
tabular information required for use of the DCK' s in the given 
overlay. This PSK will probably be present on all overlays. 
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It is interesting to note that the on-line system must have 
the capability of permitting the operator to use several 
techniques for "defining" operands. 

(1) Selection of all or a portion of the information dis- 
played on the alphanumeric tube. 

(2) Selection by means of the light gun or cursor from the 
17- inch tube. 

(3) Direct entry of the tabular data from some external 
source such as a directory. 

(k) Generation of the data on the basis of information ex- 
tracted for an associated Display Control Key Table entry. 

In general, this will be done prior to "programming" new process 
step key operations; however, it must be possible to permit the 
definition of operands that have not been anticipated. 

i. PROGRAM - This PSK, common to all overlays, is used in the 
development of new programs for heretofore blank process step 
keys on a given overlay. The function provided by this key 
supplies one of the basic advantages of the on-line concept, 
namely the generation of new programs directly at the console. 

To institute a new program, the PSK PROGRAM is pushed, followed 
by the key to which the new program is to be attached. Then 
the sequence of operations that will make up the new program 
is entered. 

Up to this point we have indicated many of the principal on-line 
data processing routines required to construct a working data base from 
a given data base for eventual use in an Operational Overlay. It will 
be noted that the explicit steps required for formatting and placing 
the Mission Status Table (Figure k) on the alphanumeric tube and for 
programming the required process step keys have not been stated. In order 
to do so, it is necessary to: 

a. Define those items that make up the Mission Status Table. 

b. Format the data to correspond to the actual display (Figure k) , 

c. Display the data requested. 

Carrying out these operations will require the use of the process step 
keys FORMAT and DISPLAY given in Figure 10. 

In summary, the above analysis has been directed toward analyzing 
the utility routines necessary for implementing the Operational Overlay 
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PSK MISSION STATUS TABLE. A similar analysis should be carried out for 
each of the other PSK's on the Operational Overlay of Figure 2, in order 
to enumerate the desired Utility Overlay process step keys for achieving 
the required results. It is believed, upon completion of this analysis, 
that in many instances the same utility process step keys will be used 
in the generation of different operational overlay process step key 
operations, 

6.3.^ Interpretive Instructions for Utility Overlay Generation 

The last section indicated hov the on-line technique could be uti- 
lized to (a) construct an Operational Overlay from a general purpose 
Utility Overlay, and (b) define problem oriented operands. The computer 
programs behind these end results would be synthesized by an operator at 
a console to meet the specific conditions of the operational problem. 
The various programs in the Utility Overlay are essentially data 
processing routines. It is, therefore, desirable to describe the 
techniques by which these generic routines can be generated on line, 
and also the method by which they can be applied to specific problems. 
In general, each utility routine is programmed at the console using a 
sequence of interpretive commands which are executed by a basic executive 
program. It is seen that a parallel situation exists between the genera- 
tion of an Operational Overlay from Utility Overlays, and that of an 
Utility Overlay from Basic Executive Overlays. 

This section will illustrate the use of the basic executive program 
for the generation of some of the utility routines described in the 
previous section. By doing this, a part of the repertoire of interpre- 
tive instructions will be defined. 

6.3.^.1 Search Data Base 

As a first example, we shall look at the sequence 
SEARCH DATA BASE 

The operand DATA BASE will have in its associated DCK Table the 
information necessary to determine the specific basic instructions re- 
quired for the generic operation search. Let us assume that the follow- 
ing tabular information is stored in the DCK Table for display control 
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key No. 15, which has been assigned the operand "Data Base": 

Signature 0^ 

Octal Code l6 

Storage Medium Magnetic Tape 

Absolute Address 

Relative Address 

No. of Words E.O.F. (End of File) 

Thus, from an interrogation of the DCK Table entry for key No. 15, 
it is possible to determine: 

a. The operand, "Data Base", is stored on magnetic tape. 

b. The number of vords in the record is variable, since 
the basic instruction "End of File" determines the 
termination of the search. 

To carry out the above steps, the interpretive program must select from 
a library tape a routine for reading one record from magnetic tape plus 
a second routine for testing End of File. 

The selection of these routines and their proper ordering will be 
implemented or programmed by an operator at a console using a Basic 
Interpretive Instruction Overlay. For this example, the utility routine 
"Search", could be programmed from the following interpretive instruc- 
tions: 

a. READ TAPE 

b. COMPARE EQUAL (TO) E.O.F. 

with proper branching for E.O.F. Again this necessitates providing in- 
formation in the Display Control Key Table. The manual sequence of 
button pushes for executing the first of these steps is : 

PSK : READ 

DCK : TAPE RECORD 
This would access a machine language program to: 

a. Connect the tape unit to the computer. 

b. Start the tape drive. 

c. Transfer one record to the pseudo accumulator. 

Upon completion of the data transfer, queueing lights would be 
turned on under the next required sequence: 
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PSK : COMPARE EQUAL 

DCK : E.O.F. 
This again illustrates the use of the DCK Table because it is necessary 
to determine: 

a. The portion of the pseudo accumulator to be used for 
comparison. 

b. The location of the operand to be used for comparison 
with the selected portion of the pseudo accumulator. 

The sequences illustrate the requirement for telling the computer 
to execute — this, of course, vill be implemented by the PSK "(Period).". 

Thus far, ve will have read a record from tape and compared a speci- 
fied area of the pseudo accumulator with the bits that make up the E.O.F. 
character. 

Since the "Compare Equal" operation gives rise to a branch, one of 
two exits will be effected. If the E.O.F. is not detected, a queueing 
light should indicate that an interrogation of the file label is in order. 
If the E.O.F. is detected, the end of file search has been accomplished 
and a different branching will be required. 

6.3.^.2 Select Project Unicorn 

At this point we come to the interpretive instructions required for 
the second half of the utility instruction, namely 

SELECT PROJECT UM CORN 
This first involves determining if the label is "Project Unicorn" . It 
is assumed that the entire record is in the pseudo accumulator, and thus 
it is necessary to instruct the computer explicitly which portion of the 
pseudo accumulator is to be used for the test. This is slightly different 
from the requirement of indicating E.O.F. in that the latter, when it 
occurs, will occupy the entire pseudo accumulator, while only a portion 
is used for the label. It is, therefore, necessary to define the perti- 
nent portion of the pseudo accumulator. In an automatic system, the 
capability of defining the relative location of a specified portion of 
the record requires a dictionary for fixed length records or identifica- 
tion of the number of characters, say for each generic group in a 
variable length file. 
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In the on-line sense we wish to establish a nomenclature or 
syntactic set of rules by which identification of elements of an 
operand can be located within the pseudo accumulator. Two techniques 
appear feasible at this time: 

a. An operation, denoted by the Basic Instruction Overlay PSK 
FLAG, can be defined as the capability of isolating one parti- 
cular group of characters within the pseudo accumulator. This 
group becomes the source data for the subsequent interpretive 
operation. In this case, FLAG will be followed by the operand 
denoted by a DCK LABEL. Pressing the key LABEL will extract 
from the DCK Table the necessary data for locating the re- 
quired group of characters. In summary, the keys used are: 

PSK : FLAG 

DCK : LABEL 

b. As an alternate procedure, a syntactic rule can be established 
to the effect that: "If an operand precedes an operation, 
then the source of the operation is determined by the contents 
of the DCK Table for the leading operand." Thus, the key pushes 

DCK : LABEL 

PSK : COMPARE EQUAL 

would imply that the "compare" operation would have as its 
source the portion of the pseudo accumulator determined by the 
relative position and number of characters in the DCK Table 
for LABEL. 

The present investigation has not provided sufficient insight to 

determine the preferred alternate. Analysis of additional problems will 

permit an evaluation of the above techniques and provide a basis for 

recommending one or the other. 

If we assume that the latter is preferable, the sequence of button 

pushes would be: 

LABEL 

COMPARE EQUAL 

PROJECT UmCORN 

which would effectively compare the specified portion of the pseudo accumu- 
lator with the identifier "Project Unicorn". We have thus specified a 
sequence to implement the specific request, SELECT PROJECT UNICORN. 



a. 


DCK 


b. 


PSK 


c. 


DCK 



-kQ- 



6. 3 A. 3 "Search" va "Select" 

The above dlscusBlon can "be used to illustrate the essential 
difference between the operations "Search" and "Select". 

In the case of "Search", there is an on-line implication that a 
storage mediiim must be described and some connotation is required to 
denote when to end the search. In some cases it may be necessary to 
describe the search technique as to content or location address. In 
any case, it is possible to describe the search desired with very few 
descriptive terms. As such, this lends itself to the concept of imple- 
mentation via a general purpose or Utility Overlay. 

On the other hand, the operation "Select", in many instances cannot 
be described so succinctly and, in addition, may be constrained by 
various problem- oriented parameters. It thus seems necessary to provide 
the capability for such operations as "Select" by means of special over- 
lays. These special overlays will be called "Service Overlays". They 
will be characterized by the fact that 

a* the operands are problem-oriented, 

b. a limited set of process step keys are utilized, 

c. specialized applications are of frequent occurrence. 

6.3»^»^ Service Overlay 

As an example, the Service Overlay, "Select" (Figure 11), contains 
those interpretive instructions which can implement this function of 
choosing by various criteria. These would include comparison for equal 
to, greater than, smaller than, and for various logical and arithmetic 
delimiters. 

The operator would thus form a "program" for a particular problem 
using this Service Overlay. This program would be transferred to specific 
process step keys by use of the PSK PROGEIAM on either the Utility Over- 
lay or directly on the Operational Overlay. 

^•3»5 Summary of Software System Characteristics 

The above discussed software system is predicated upon the existence 
of a magnetic tape file associated with each console overlay. This file 
contains the parameters, data, and programs required for the execution 
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of the commands as specified by the depression of console keys. 

Thus, one of the most important aspects of implementing an on- 
line command and control system appears to "be the incorporation of 
a capability for the generation of these files. This note has briefly 
described several preliminary items that should be included in the 
display control key and process step key tables. The various programs 
associated vith the process step keys are undoubtedly susceptible to 
modification because of syntactic irules. It is thus envisioned that 
these routines will probably have to be stored on tape in a relocat- 
able binary form. 

Several levels of coding can be enumerated at the present time - 
as further investigation is made, it may be necessary to list other 
levels. They are: 

a. Machine level coding of the interpretive control program and 
the various interpretive commands of the interpretive system 
repertoire. This is at the basic machine programming level, 

b. Utility overlay routines which are mainly concerned with 
manipulation of data within a given configuration of hardware. 
These would include such programs as "Search Drum", "Search 
Tape", "Display on Alphanumeric Tube", "Display on IT-inch 
Tube", "Print", etc. 

c. Service overlay routines which are primarily application 
dependent data processing programs such as "Select", "Sort", 
etc. 

d. Operational overlay programs which are at the top of the 
hierarchy of overlay programs, being composed of programs 
generated at the previously mentioned levels. 

Among the duties of the interpretive control program will be the following: 

a. Interpretation of signals from the console. 

b. Transfer of control to specified locations in accordance with 
stipulated syntactical rules. 

c. Dissemination of error and warning messages when required. 

d. Monitoring of the sequential operations having the pseudo 
accumulator as either the source or target location. 
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It is thus conceived that the available repertoire of basic inter- 
pretive instructions would be available on one or more overlays. These 
will generally be combined by a "systems operator" into special purpose, 
service, and utility overlays similar to those described herein. Opera- 
tional overlays could then be compiled on-line using all of the overlay 
tools previously developed, including a capability of using machine 
language programs if and as required. 
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APPENDIX A 
THE m-kOO DATA PROCESSING FACILITY 



The specific data processing facility including the console, used 
in the discussion, is the AN/FSQ-27 or RW-^OO system. This system has 
been successfully employed in the TRW on-line scientific problem solu- 
tion system. It should be emphasized that, although the discussions 
deal with the RW-^00 system, the on-line technique can be modified to 
meet the peculiarities of other computer systems . 

A-1. RW-ifOO DATA PROCESSING SYSTEM 

This system is made up of modules connected to each other through 
a central switching device -- the Central Exchange. For use in on-line 
command and control applications, the following modules are considered 
pertinent : 

a. Computer Module, a general- purpose, parallel, binary, two- 
address fixed- point, two's complement arithmetic digital computer with 
l,02i|- words of random access magnetic core memory. 

b. Central Exchange, a central switching device with its own 
magnetic core memory which allows the programs to use symbolic address 
and provides for a master computer to force disconnect other modules in 
the system. 

c. Drum Module, a magnetic drum used for Intermediate storage with 
a 17 ms maximum access time, 8192 words of storage, and 6l, 000- word- per- 
second transfer rate. 

d. Drum Module B, a large magnetic drum having a storage capacity 
of 7978T2 words with 13 ms access time and a transfer rate of 50,000 
words per second. It Is anticipated that this drim will be the principal 
medium for auxiliary storage of programs and data at the working level. 

e. Buffer Module, a unit designed to provide buffering between 
the high-speed computer, the computer module, and low-speed peripheral 
equipment, and also to provide search and other slow-speed operations 
while the computer is performing other operations. Each half buffer has 
a 1,02^4- word core memory and a data transfer rate with the computer of 
75 > 000 words per second. 
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f . Display Buffer, a source of regenerative digital data for 
generating symbolic or alphanumeric displays on the DAC. Computer 
words can he transferred at the rate of 15,000 per second. 

g. Tape Module, an Ampex FR 300 unit vith 90-incheB-per-second 
normal and 150-inches-per- second high speed capahilities. The tapes 
have a density of 139 vords per inch and are provided in 2,500 foot 
reels. All overlay programs (Section 5«2) vill be permanently stored 
on magnetic tape, 

h. Display Analysis Console (DAC), the module which provides the 
interface required for expedient man-machine communication. Because of 
its importance to the on-line system, further details are provided in 
the following section. 

A- 2. DISPLAY ANALYSIS CONSOLE 

The Display Analysis Console (Figure A) contains two 17-inch 
cathode-ray tube displays for line drawings, dots, and other special 
symbols and one 10-inch alphanumeric display tube. The last has a 
capacity for 6kO characters in 20 rows of 32 characters each. 

For data retrieval, presentation, and control, the console contains 
several keyboards and other controls. The Process Step Keys (pSK's) 
consist of a group of 30 pushbuttons, each one of which generates a 
unique code when depressed. Plastic overlays with holes in them for 
the keys to pass through can be placed over the keys. When any one of 
the 62 overlays is in position, it automatically sets a group of switches 
for notifying the computer of the overlay in place. These keys are used 
to designate operations in the on-line command and control system of this 
note (in the scientific system, they designate the functional operations 
as add, integrate, etc.). 

Each of the 2k Display Control Keys (DCK's) generates a typical 
signature and a unique message when pressed. These keys are used in 
the on-line command and control system to designate the various applica- 
tion-oriented operands of a specified overlay. In general, the meanings 
of the individual keys vary in the same manner as the programmed assign- 
ments made to the process step keys vary for each overlay. For one PSK 
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Figure A, Disp3ay Analysis Console 



overlay, the DCK's are programmed for alphabetic entry onto the 10-lnch 
alphanumeric tube. (There is a separate numeric entry keyboard.) 
Other control panel features of the DAC include: 

a. Light gun used on either 17-inch tube for specifying the 
storage cell of a symbol light gunned. 

b. Cross hair cursor used on either 17-inch tube for indicating 
the raster points of the intersection of the cross hair. 

c. Square shaped symbol used as a marker on the 10-inch alpha- 
numeric tube. Conventionally it has been used to indicate, under program 
control, the location of the next symbol to be entered on the tube. In 

a different context the marker can become a vehicle for the Retrieval of 
information displayed on this tube. 
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